OpenEdge Development:<br />Debugging and Troubleshooting Attach to Process dialog box

Attach to Process dialog box

The Attach to Process dialog box lets you attach the Debugger to a running client process. Optionally, you make the process debug-ready and attach to it in a single step. For more information on making a process debug-ready, see the "Making the process ready for debugging" section.

Figure 3–3 shows the Attach to Process dialog box.

Figure 3–3: Attach to Process dialog box

Access this dialog box by choosing Debug Attach to Process after starting the Debugger in attachable mode. Choose either of the following options:

Choose the first option if you want to make the process debug-ready and attach the Debugger to the process. You can choose this option only if the process is running on the same machine as the Debugger. Choosing the Get List button lets you select an existing process in the Select Process dialog box. For more information, see the "Select Process dialog box" section.

Choose the second option if you have already made the process debug-ready (using either the -debugReady startup parameter or the proDebugConfig command). You must choose this option if the 4GL Engine is not running on the same machine as the Debugger.

To make the process debug-ready and attach to it:

Select the Make debug-ready and Attach (local host only) radio button.

Enter the Process ID of the process on the local machine that you want to debug.

Choose the Get List button to list the currently running OpenEdge processes in the "Select Process dialog box" section.

Enter a port number that you want to use for communicating with the client process, or leave the default zero (0), for the 4GL interpreter to determine a usable port number.

Choose the OK button.

Upon a successful connection, the Debugger displays a message showing the port number that it is using for the connection, in case you need to reconnect, for any reason. After the dialog box closes, the 4GL interpreter gives control to the Debugger, and the listing for the currently running procedure appears in the source code pane, at the point where the Debugger connection was acknowledged. For hidden procedures, the source code pane appears empty, but the Debugger announces the connection and indicates that the interpreter will break at the first line of application code. Debugging can proceed as described for all other modes.

If the connection is unsuccessful, the Debugger displays an alert box reporting the reason for the failure. For information on possible reasons for the failure, see the "Using the proDebugConfig command" section.

For an AppServer process or WebSpeed agent, if the Debugger successfully alters the debug-ready state, it writes the status (on or off) to the log file.

To attach to a process that is already in a debug-ready state:

Select the Attach to debug-ready Process radio button.

Enter the name of the host on which the process is running, or accept the default localhost. You must enter a host name if the process is not running on the same machine as the Debugger.

Enter the port number used to make the process debug-ready. For more information, see the “Making the process ready for debugging” section on page 2–12.

Choose the OK button.

After successfully connecting, the dialog box closes, and the 4GL interpreter gives control to the Debugger. The listing for the currently running procedure appears in the source code pane, at the point where the Debugger connection was acknowledged. For hidden procedures, the source code pane appears empty, but the Debugger announces the connection and indicates that the interpreter will break at the first line of application code. Debugging can proceed as described for all other modes.

If the attempt fails because the process was not in a debug-ready state, the Debugger reports only that the connection attempt timed out (it does not recognize that the process was not in a debug-ready state). The attempt can also fail because you specified an incorrect host name or port.

Note: In attachable mode, when the top-level procedure terminates, possibly returning control to the Procedure Editor or AppBuilder, the Debugger window does not automatically hide, but remains in view.

If control does return to the application development environment, you restart debugging on the application by choosing Compile Debug. At that point the 4GL interpreter gives control to the Debugger, stopping at the first executable line of the application, just as it would if you had not attached.